昨天決定加入自動恢復。依照規則，背景工作查到庫存已扣減，就同步訂單狀態；仍在處理，就稍後再查；符合補送條件時，才沿用原識別重試。

規則很清楚，實作時可以先拆成三個部分：

1. 取得資料：找出待確認的訂單，取得原本的庫存操作識別。
2. 判斷下一步：根據庫存查詢結果與目前訂單狀態，決定接續處理、等待或補送。
3. 執行後續行為：依判斷結果補送，或把已完成的結果接回既有訂單流程。

前兩項看得出要讀什麼、判斷什麼。最容易被低估的，是第三項裡的「接回既有訂單流程」。

「同步訂單狀態」，同步的不只是一個欄位

假設原本的正常流程是：庫存扣減成功後，執行一段「訂單處理完成」的既有邏輯。它會更新訂單狀態，也會建立出貨工作、寄出訂單確認通知。

如果恢復流程把「同步訂單狀態」理解成更新狀態欄位，畫面會顯示處理完成，報表數字也正確，測試同樣能通過；但這張訂單不會出現在倉庫的出貨清單裡，客戶也收不到通知。

反過來，若直接重跑整段「處理訂單」，又可能連同庫存扣減一起再執行一次。真正要接的，是扣減成功之後的那一步：它需要哪些資料、會帶出哪些副作用、是否只接受特定狀態的訂單，都要對照既有程式確認。

所以第三項不是「改一個值」，而是「從既有流程的哪個入口接進去」。入口沒找對，前兩項做得再正確，結果也不完整。

拆到看得見接點與依賴

拆解的尺度，可以用三個問題判斷：這一段負責什麼？需要哪些資料與前提？會接到哪裡、帶出什麼結果？

能回答這些問題，就有了可以實作與討論的範圍，依賴也會跟著浮現：查詢需要原操作識別，判斷需要查詢結果與目前訂單狀態，接回完成流程則要先弄清楚那段邏輯的使用條件。先釐清會影響後續做法的地方，後面才不會越寫越需要回頭改。

拆得過細也有成本。每個欄位、方法與判斷分支都列成工作，反而容易看不見整段流程。粒度以自己能掌握、團隊能討論為準。

AI追查程式時，也很可能找出「訂單處理完成」還會建立出貨工作，並提出沿用它的方案。這時值得對照的是它沿用了哪個入口：方法名稱相近，不代表使用條件與副作用相同。

接回去之後，用完整情境檢查

以「庫存已扣減，但回應遺失」這筆訂單為例，恢復流程應該查明原操作的結果，並接續訂單處理：庫存只扣一次，出貨工作只建立一次，通知也只寄一次。每一段各自正確之外，還要確認接起來之後，原本成功處理時會發生的事沒有少，也沒有多。

從一顆重新處理按鈕開始，這幾天其實都在處理同一件事：規格寫清楚了要做什麼，放進現有系統時，還要知道它會碰到哪些既有的狀態、容量與流程。

拆解問題，拆到最後要找的是接點。新流程接進既有流程的地方，決定了原本該發生的事，會不會少做，或多做一次。

「自動恢復上線了，三十張卡住的訂單全部變成『已完成』。」
「太好了，倉庫今天一定很忙。」
「沒有，倉庫說今天一張出貨單都沒收到。」